A typical automobile includes a myriad of sensors mounted around the engine and other vehicle modules for monitoring the condition and selected performance characteristics of the vehicle such as air intake, temperature, and the position and rate of change of the accelerator, etc. Typically, an engine computer, also referred to as a Powertrain Control Module (PCM), is provided in the vehicle for monitoring the sensors and providing control of various engine functions as a function of sensor data. The PCM typically makes adjustments to minimize exhaust pollution, minimize fuel consumption, and maximize engine power.
Partly in response to governmental vehicle pollution mandates, an OnBoard Diagnostics (OBD) system is typically provided in the vehicle in order to require the PCM to actively monitor and test the engine parameters and in particular, the emissions-related elements. The OnBoard Diagnostics system requires that sensors and actuators controlling pollution monitoring are checked regularly and codes generated if a fault is detected. Other diagnostic systems such as OBD-II go a step further and require the PCM to actively monitor and test the emissions-related elements. An OnBoard Diagnostic port is typically provided which enables access to the engine computer and the diagnostic codes provided by the OBD system. The diagnostic port is typically accessible from either under the hood or from the interior passenger compartment of the vehicle to facilitate monitoring and control of the vehicle's engine characteristics. Conventionally, the monitoring and troubleshooting of identified faults required the use of bulky, complex equipment that was available only at automobile repair establishments. The operation of the conventional test equipment also required the knowledge and skill of a trained mechanic.
Many vehicle operators also desire the capability to accurately control, monitor, and evaluate vehicle performance themselves without the need for bulky, complex equipment or a mechanic. The diagnosing of certain engine problems and the monitoring of certain engine performance characteristics conventionally requires the use of a dynamometer. A dynamometer or “dyno” is a device used to measure power and torque produced by the engine. There are typically two types of dynos, an engine dyno that gets bolted directly to an engine, and a chassis dyno that can measure horsepower and torque without requiring that the engine be removed from the frame of the vehicle.
A vehicle operator may also be interested in measuring the speed performance of the vehicle, e.g., quarter mile time, time to speed, and top speed. Conventionally, a drag strip or other location is used and requires another person and/or one or more external devices to monitor the vehicle position and to provide a timer for determining the quarter mile time and speed.
A vehicle operator typically also desires to have a display of vehicle operating conditions. The cost of accessory gauges to display these operating conditions, however, are often cost prohibitive and difficult to install. Vehicle operators are also typically interested in having ready access to diagnostic data and their descriptions for troubleshooting purposes.
Known devices exist for separately programming the engine functions in order to enhance vehicle performance. However, such devices are stand-alone devices that do not include the other functions.
There is therefore a need for a multipurpose system that provides a performance tuning function, a dynamometer function, and a drag strip function via a portable device that a user can readily install by plugging it into the diagnostic connector port of the vehicle. There is a need for a system that also enables a user to monitor selected characteristics of the engine and other vehicle systems.
There is a need for a system that also enables a user to selectively display diagnostic data based on data read from the onboard diagnostics system port. There is also a need for displaying vehicle operating conditions to a user without the need for costly accessory gauges.
A need also exists for providing the above features in a device that has a user friendly interface for enabling easy operation of the monitor, evaluation, and control functions.
The PCM software of the engine computer calculates the velocity data accessible from the diagnostic port based on “time between pulses” measured by a sensor on the output shaft of the transmission. The output shaft rotates at the drive shaft rotational speed such that there are one or more pulses generated every time the drive shaft turns one complete revolution. The engine computer cannot deliver the first velocity value based on time between pulses, until after the first two pulses have occurred.
In order to accurately measure the time and distance down the track from the very start, the distance and time measurements must begin simultaneously at the precise moment the vehicle moves. The time interval and the short distance traveled from “first movement” until the first pulse is not known based on any of the data available from any known diagnostic port 2. In other words, the vehicle might be at rest with the sensor on the output shaft of the transmission on the verge of “triggering”, or it might be at rest with the sensor having just “triggered”, or it might be anywhere in between. As a result, there is an unknown error such that any previous attempts at using PCM velocity values provided at the diagnostic port to generate distance traveled and acceleration tests have always contained an error that varies from test to test randomly, and, therefore, gives false, unreliable fluctuating results.
There is therefore a need for a detector for detecting the start time of first movement of the vehicle independent of the on board diagnostic system and its diagnostic port. A “first movement” trigger is needed such that the precise time taken to reach the first PCM delivered velocity value can be accurately determined.
The start time allows development of an accurate time line, however, the distance from first movement to the first velocity value from the diagnostic port is still unknown. Wheel spin presents another challenge because the velocity values from the diagnostic port are distorted during the time the vehicle's wheels are spinning, such that distance calculations would otherwise be inaccurate. Wheel spin of varying times and distances down the track would seem to make accuracy impossible. Conventional methods simply count off for wheel spin and do not accurately account for errors induced thereby in the velocity data.
There is therefore a need for a method that accurately and reliably accounts for the unknown distance between pulses that causes an error at the start of a test run and detects and accurately and reliably accounts for wheel spin.